Add support for JWS unencoded detached payloads #270
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
|
Hi @visav-tietoevry thanks for opening this PR and sorry for the late reply. We've just re-booted the project and released a new 3.0.0 release. I will have a look at your PR in the coming weeks. We're planning to include it in the next release. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
Add option to skip base64url encoding of payload in JWS. This results in a compact serialization with detached payload.
Motivation for not encoding the payload is further described in RFC-7797 JSON Web Signature (JWS) Unencoded Payload Option.
One example use case where unencoded payload is needed is implementing
JsonWebSignature2020for JSON-LD document proofs. In this case, JWS is used as a signature, and the document itself is not embedded in the JWS. This suite takes JSON-LD document & it's proof without signature, does some steps to normalize them, computes SHA-256 digests, concatenates them and forms a JWS from this result, without using base64url encoding. Finally, resulting JWS is added to the document proof segment, without payload. Verifying end can then reproduce the steps to create the payload for JWS and verify the signature.Changes
"b64"header parameter support toJWSHeaderto enable unencoded payloadasJOSESigningInput()withJWSSigningInputstruct, which now contains the logic for signing input, controlled by"b64"header parameterJWSwith detached payload, to enable verification of (unencoded) detached payloadsCaveats
JWSwith"b64"header parameter always yields a serialization with a detached payload. This was a choice to limit the scope of the PR to get minimum viable support for unencoded payload option.Remarks
Following tests were failing for me at
master(d542b31):testDecryptingAliceSecretWithBobKey()testDecryptingBobSecretWithAliceKey()These test failures are not related to changes in this PR.
Tests
I found it a bit difficult to find a proper home for the unit tests of the added JWS functionality, so I chose to make a new test case class,
JWSUnencodedPayloadTests, which was arbitrarily inherited fromECCryptoTestCaseto get the required dependencies for signing & verifying.I think these unit tests should be agnostic of the signature algorithm, but I couldn't find an easy way to do so without doing some bigger refactoring. If there's a simple way to mock
Signer, please let me know.